Component Technologies

• What is a Component? provides a brief definition, and mentions some component technologies that exist on various platforms.
  
  
• Types of Components lists a number of types of components. Most of these represent relatively new technologies like OpenDoc, SOM, and Java. You will see in this topic that writing component software is definitely state-of-the-art stuff!
  
  
• Parts vs. Libraries discusses the architectural question of when should you build an OpenDoc part, as opposed to provide the same functionality as a SOM library. It also describes a common architecture in which an OpenDoc part may use the services of a SOM library for part of its functionality.
  
  
• Inter-Part Communication introduces various ways that separate OpenDoc parts can communicate with one another. Part-to-part communication is essential for solving common kinds of problems, such as the case where a part may be displaying some representation of data that is actually stored in another part.

What is a Component?

A component can be defined as simply a reusable piece of functionality. As described in more detail below, a component can be an application, an OpenDoc part, or a shared library.

Many different platforms support component technologies. Two component technologies that have been around for years include Apple's HyperCard with add-in XCMDs, and Microsoft's Visual Basic with VBX controls. There are even component technologies associated with specific applications, such as "plug-ins"that can be added to Adobe Photoshop, Macromedia Director, or Netscape Navigator.

What's special about OpenDoc as a component technology? First, it supports an open, industry-standard API, as opposed to the APIs for a Photoshop plug-in which are limited to adding features to a single application. Second, OpenDoc is a compound document architecture which supports parts being embedded in other parts. The only major component technologies that support embedding are OpenDoc, Microsoft's OLE, and Sun Microsystems Java Beans (we did not make up that name).

Of these, OpenDoc is the only shipping compound document technology with cross-platform support for Mac, Windows, UNIX, and OS/2, as diagramed below. OpenDoc has therefore been adopted by OMG as an open standard for compound documents. A good introduction to OpenDoc from the user's perspective can be found on the Web. A technical introduction to OpenDoc and OpenDoc programming can be found on the Web, in a course created by Apple's Developer University.

Types of Components

Here are some types of components that you can use to assemble solutions to customer problems:

SOM Libraries. SOM allows the creation of fully object-oriented shared libraries. These libraries are language and compiler-neutral, meaning that you can implement a library using one language, and call it from a different one. These libraries fully support object-oriented programming, so you can make a new library by subclassing from an existing one, and adding functions or overriding existing functions.

This may not impress you, until you realize that other technologies do not do this. For example, Apple's Code Fragment Manager does not allows the creation of language-neutral object-oriented libraries, since method dispatch varies from one compiler to the next, even with the same language, such as C++. Microsoft's COM does not allow inheritance. Another great advantage that SOM has over COM and other component systems is that SOM is CORBA-compliant.

OpenDoc parts. OpenDoc parts can be used by developers or power users to assemble new solutions. An OpenDoc part is a visible component, since it usually has a user interface with menus, windows, response to mouse clicks, etc. OpenDoc parts can be as simple as a reusable button, as described in the Decision Support Case Study, or as complex as a complete 2D color drawing program like ODFDraw. See the section on Reusable Components for more detail on where you can get components that someone else has already developed.

OpenDoc part editors are actually constructed as SOM shared libraries, which means that every OpenDoc part is a specialized SOM object. OpenDoc parts are specialized in two ways, compared to simple SOM objects. The differences are:

- a custom SOM library can be defined with any API you choose, while an OpenDoc part must support the standard APIs defined in OpenDoc for event handling, drawing, data transfer, etc.

- a custom SOM library usually will not have a user interface, but just provide some set of services. An OpenDoc part generally will have a user interface.

You are generally encouraged to actually build two versions of your code: a part editor and a part viewer. The editor allows the user to create and edit the data, while the viewer does not have the capability to edit the data or save changes. In many cases, editors may be commercial products that are sold, while the matching viewer may be freely distributed so that users can at least see the contents of a part. There is good on-line documentation for programming with OpenDoc on the Web.

Container applications. Ordinary applications can be converted to be containers for embedded OpenDoc parts. One commercial application that has been converted to a container application is RagTime, while Claris will be releasing a version of ClarisWorks as a container application in the future. There is a demo version of ClarisWorks as a container on Apple's DR5 CD-ROM.

Scriptable applications. "Applications are components?", you say. Why, yes, they can be. A scriptable application can be combined with scriptable OpenDoc parts to make custom solutions. Tools like FaceSpan let you easily put a custom user interface on OSA-compliant scripts, and drive the operation of both parts and applications.

OpenDoc shell plug-ins. These provide a mechanism for extending the capabilities of the OpenDoc document shell. Typical uses include:

- installing a dispatch module to modify how events are handled.

- installing a spell-checker object to be accessed as a service by all parts in a document. A commercial example of a shell plug-in is Part Merchant's PMFinder, which provides an Internet-based service to enables users to access and download missing part editors.

- replacing parts of OpenDoc, including entire OpenDoc subsystems.

Java applets. There is a special OpenDoc part being developed that allows a Java applet to execute inside an OpenDoc container. This means that you could create an applet using a Java development system like Symantec's Café or Metrowerks CodeWarrior, and then use it like a simple OpenDoc part. Better yet, you could create an cool little animated applet using a totally visual environment like WebBurst from PowerProduction Software. You could then drop this into an OpenDoc container and use it as a cool little OpenDoc part, created in minutes without having to write any C++.

Netscape plug-ins. These are programs that were designed to be executed from within the Netscape Navigator Web browser. They normally display data inside a rectangular frame in the browser. This is similar in concept to a simple OpenDoc leaf part embedded inside an OpenDoc container. A special OpenDoc part editor has been developed that can wrap a Netscape plug-in and allow it to be embedded inside an OpenDoc container. Therefore, to some degree you can do OpenDoc development by writing a plug-in.

OLE objects. Object Linking and Embedding is Microsoft's preferred component technology. See the OLE web page for more information. OpenDoc will be providing a component glue architecture that allows interoperability between OLE objects and OpenDoc parts.

Part vs. Libraries

You can use both OpenDoc parts and SOM shared libraries when assembling customer solutions. In fact, we recommend using SOM shared libraries to help build any complex OpenDoc parts. The diagram below shows two different ways to build an OpenDoc part.

The "Combined design" on the left shows the most common way to build a part. With this design, the code for your part includes both support for the OpenDoc APIs and for the problem-domain specific code - in the same project. This domain-specific code might be for doing financial calculations, image processing, chemical simulations, etc.

The "Factored design" on the right shows what is often a better solution, in that the domain-specific code has been factored into a separate SOM shared library. Why is this better? First, it allows you to work with two small projects rather than one larger one. This generally makes it easier to develop, debug, and test the code. Second, the problem-domain library can be called from many different parts or even applications. Since SOM libraries are shared libraries, this can lead to more efficient use of disk space and RAM. Third, you may even decide to build the OpenDoc part with one technology, such as a RAD tool like AppWare, while building the SOM library with different technologies, such as C++ and ODF.

As a general rule, we suggest that you consider finding the parts of your code that represent calculation "engines" and "servers"and developing those pieces as separate SOM libraries. Then build OpenDoc part editors as a mechanism for putting a user interface on that functionality.

In many cases, you will need to create a suite of parts that can work together to solve a problem. In the Case Studies section of these notes, for example, we describe a set of parts for an enterprise Decision Support System to provide access to sales and product data that uses linked parts. We also describe a physics simulation that uses parts that communicate using OpenDoc extensions. In this section, we'll review mechanisms for supporting inter-part communication. These include mechanisms that are only available to the programmer, and other mechanisms that are also available to the end user.

End-user mechanisms include:

Embedding
Linking
Scripting

Programmer mechanisms include:

Apple Events
SOM Libraries
OpenDoc Extensions
OpenDoc Namespaces

Embedding provides a way for a user or a developer to group related parts together. The user can assemble parts into a container, or the developer can do this for the user and deliver stationery that has parts already assembled together.

Linking provides a way for the user to transfer data from one part to another. If the linked parts are in in the same document, the destination data can be "hot linked" to the source, so that the destination data will change as soon as the source data changes. If the source and destination parts are in separate documents, then (on the Macintosh) the link will be updated when the user Saves the source document. The user can create a link using Copy and Paste As...

Scripting provides a way for the user to automate the behavior of both applications and OpenDoc parts - provided that the developer has written the extra code necessary to support scripting. Scripting does not come for free when developing OpenDoc part editors, but there is considerable support for it built into ODF. Apple's scripting architecture is based upon sending and receiving Apple Events.

Apple Events are high-level events generated by software, as opposed to user events like key-down and mouse-down events. You can create Apple Events in one part, and send them to another part, or even to an traditional application. One great virtue is that Apple Events can be sent across the network, as opposed to linking, which can only be set up between parts on the same machine. Apple Events provide a relatively low-bandwidth form of communication under System 7.x, but will be a much higher-bandwidth mechanism under the upcoming Mac OS 8.

SOM Libraries are object-oriented class libraries that use SOM as the object run-time system. In some cases, you may design a SOM class to support inter-part communication. You might create one instance of this class that could be accessed from more than one OpenDoc part. In that case, the SOM object could keep track of shared data.

Extensions allow you to define custom APIs for a part. For any part editor, you can create an associated extension object to provide additional interfaces to the part editor. Other part editors can then access extension object and call the new interfaces. There will be at least four classes of extensions:

• Standard extensions that almost any part might implement, such as extensions for scripting and Cyberdog.
• Public extensions for specific data types such as extensions for text parts that might want to support spell-checking services. These extensions might be managed by CILabs.
• Private extensions that you might define just for your suite of parts. No one else might ever know they exist.
• Semi-private extensions that you might define for use by you and third-parties. These extension APIs would be published to encourage development of compatible parts by third-parties. These extensions would be analogous to today's Photoshop or Netscape plug-ins.

Namespaces provide a general-purpose registry mechanism. A name space is an object that maps data types to values. You can use them to define global spaces in which to share information with other parts. For example, you can use a name space to create palettes to be shared among several parts. Each OpenDoc session provides a run-time service allowing you to define name spaces. The name-space manager keeps a list of all currently-defined name spaces.

©1996 Apple Computer, Inc.

Last modified by DAW on 12-July-96